home *** CD-ROM | disk | FTP | other *** search
/ STraTOS 1997 April & May / STraTOS 1 - 1997 April & May.iso / CD01 / INTERNET / SITES / RAND / UNSPLIT / text1069.txt < prev    next >
Encoding:
Text File  |  1997-02-06  |  3.0 KB  |  98 lines
  1. > > To get some more water on the wheel, I tested memspeed yesterday on my Afterburner040.
  2. > ...
  3. > > With memspeed I get 4.9 MB/s to ST-RAM read and slightly less write.
  4. > 
  5. > In what graphics mode?
  6.  
  7. Yeah, in what graphics mode ?
  8.  
  9. (256 colors I hope :-) )
  10.  
  11. > > To TT-RAM I get 35.9 MB/s read and 16 MB/s write.
  12. > 
  13. > That sounds rather low, but see below.
  14.  
  15. Esspecially the write-access.
  16.  
  17. > What did you get on cache accesses?
  18. > 
  19. > Only 9 million 32 bit read accesses and 4 million write accesses per second.
  20. > Even a standard Falcon comes close to that for writes (even if they're only
  21. > 16 bit in that case). I guess the '040 might have to read the entire cache
  22. > line first when writing, though, unless you use move16.
  23.  
  24. I don't think MEMSPEED.TOS was intended for a 68040 testing. It was programmed 
  25. on a TT030 back where the 68030 was a hot CPU.
  26.  
  27. > Shouldn't burst mode do better than that?
  28.  
  29. OOOhhhhhh my my, indeed. You can count on that ! :-)
  30.  
  31. > (Assuming the AB040 does burst, which seems likely.)
  32.  
  33. I can't see, why it shouldn't have it. It has a full-spec. 32-bit BUS with 
  34. the BUS clock being the external CPU clock.
  35.  
  36. > According to Motorola's 680x0 optimization document:
  37. > Saving/restoring registers:
  38. > 
  39. >    A:   movem.l   d4-d7,-(a7)   B:  move.l   d7,-(a7)
  40. >                                     move.l   d6,-(a7)
  41. >                                     move.l   d5,-(a7)
  42. >                                     move.l   d4,-(a7)
  43. > 
  44. >    68000/20/60/xx:   A
  45. >    68040:            B (if time critical)
  46. > 
  47. > Which suggests that using movem for memory speed test isn't a good idea
  48. > on that processor. I've no idea how large the difference is, though.
  49.  
  50. It's funny that the 68060 doesn't act the same way as the 68040 in that 
  51. regard.
  52.  
  53. > Trying to figure out the instruction timing tables is not simple, but to me
  54. > it looks like succeding MOVEMs with four registers will take seven cycles
  55. > each, while four simple MOVEs will only take four cycles.
  56. > That is, it _might_ be possible to almost double the figures.
  57.  
  58. Sounds reasonable enough. And me who always thought that `movem' was always 
  59. faster than every other move-instruction, no matter what brand of 68xxx CPU.
  60.  
  61. > Doug has probably already figured out the correct numbers. ;-)
  62.  
  63. You can count on that :-)
  64.  
  65. > > One interresting thing is that when I run GEM-Bench and test the AB040 against
  66. > > the Medusa040 the AB040 is actually more than twice as fast at RAM-Access and
  67. > 
  68. > Strange.
  69.  
  70. Yes, that's _very_ strange.
  71.  
  72. > > also faster than MagiC Mac running on a 040 MAC. Not a big difference though.
  73.  
  74. I had similar experience under MagiCMac on my Mac.
  75.  
  76. > What kind of Mac was that?
  77.  
  78. My Mac is a LC-630 with a 33 Mhz 68lc040 CPU.
  79.  
  80. > > BTW. My program is called memspeed.tos, not ttp. :-)
  81. > 
  82. > Well, that might be true for mine as well.
  83. > What version? I have 1.0.
  84.  
  85. Same here too.
  86.  
  87. By the way, I found the reason for my ST-RAM access quotes.
  88.  
  89. It was in 640x480 16 colors and in 36/18 Mhz mode, therefore the bigger numbers.
  90.  
  91. I'm sorry for giving misleading information.
  92.  
  93.  
  94.     Keep Cool and Flying...
  95.  
  96.     ChainXOR...
  97.  
  98.